Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.00%. Comparing base (c0e97b0) to head (852b766).
⚠️ Report is 76 commits behind head on main.

❌ Your changes status has failed because you have indirect coverage changes. Learn more about Unexpected Coverage Changes and reasons for indirect coverage changes.

@@            Coverage Diff             @@
##             main    #1955      +/-   ##
==========================================
+ Coverage   84.11%   85.00%   +0.88%     
==========================================
  Files         198      181      -17     
  Lines       22241    13074    -9167     
  Branches     4687     1206    -3481     
==========================================
- Hits        18709    11113    -7596     
+ Misses       2610     1778     -832     
+ Partials      922      183     -739     

Good catch!
Sneaky bug indeed.

However, should we look into why an uninitialized v2d gets a random value? I would think the serialized value of an "empty" v2d should be null, [] or even [0,0]?
Perhaps we should look at the otio implementation of v2d? I assume the random values stem from old data in memory at some location, but I'm in no way a C++ expert

The default v2d constructor in C++ doesn't initialize the values, so it can be any random memory value as you point out. This is done on purpose, I believe as an optimization. For example if you create a vector of ten thousand v2d values, you might not want the overhead of assigning zero to all of them.

I'm not a Python expert, does Python have the concept of uninitialized values? Maybe the Python bindings should initialize the values unlike the C++ code.

It's also interesting that the serialization fails, but maybe crazy numbers like 3.503154865959304e+151 aren't handled.

Python doesn't have that notion, and some languages are moving away from uninitialized variables as a guard against unexpected bugs or security issues (e.g. reading passwords from someone else's freed memory).
I think we should make that constructor initialize with zeros if possible. Maybe that's possible in the bindings layer?
With that said, I would happily accept this PR as-is and handle that task in a future PR.

It should be fairly simple to initialize the values in the bindings, I can create a separate PR for that. I think we should merge this PR so there aren't any more random CI failures. Plus using values like v2d(0.1, 0.2) is probably better for serialization tests than v2d(0, 0).